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(54) Resource retrieval over a data network 

(57) A method of downloading resources to a client 
(1) from a content server (3) over a data network. A 
resource request message is sent from the client (1) 
and is intercepted at a proxy (2) located in the data net- 
work between the client (1) and the content server (3). 
A header request is sent from the proxy (2) to the con- 
tent server (3), requesting the content server (3) to 
transmit a header, associated with the requested 
resource, to the proxy (2). The header is received at the 
proxy (2) which determines whether or not the header 
contains billing and/or access restrictions. In the event 
that the header does contain billing and/or access 
restrictions, the client's right to receive the requested 
resource is authenticated and, providing the client is 
authenticated, the resource request message is deliv- 
ered from the proxy (2) to the content server (3) and 
subsequently the resource is downloaded from the con- 
tent server (3) to the client (1). 
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Description 

[0001] The present invention relates to a method and 
apparatus for retrieving resources from a content server 
over a data network and in particular, though not neces- 5 
sarily, to a method and apparatus for enhancing World 
Wide Web services. 

[0002] The Internet is a global open communications 
network connecting a great number of local area net- 
works, such as networks of various companies, univer- w 
sities and other organizations. These networks may be 
used by a large number of independent workstations 
and computer devices. An individual client may have a 
direct connection to these local area networks or may 
be connected to them through a PSTN (Public Switched is 
Telephone Network) or an ISDN (Integrated Digital 
Services network) using a modem or similar device. 
[0003] The two most often used communication proto- 
cols for the Internet are TCP and IP (Transport Control 
Protocol and Internet Protocol respectively). In most 20 
cases the service provider provides the various serv- 
ices by utilizing so called WWW (World Wide Web) and 
HTTP (HyperText Transfer Protocol) protocols to pro- 
vide a graphical Internet interface for the client terminal 
which is typically a data processing device such as a 25 
microcomputer. The WWW contains, e.g. HTML docu- 
ments (HyperText Markup Language) i.e. "hyperdocu- 
ments", one such document forming one entity which 
can contain text, pictures, even moving pictures, sound, 
links to other documents and even links to other serv- 30 
ices. The skilled person is aware that "services" refers in 
this connection to various kinds of features, products, 
services such as electronic mail, electronic phone book, 
entertainment, assistance and advisory services etc., 
advertisement, games, videos and the like which are 35 
accessible through various communications networks. 
[0004] It is an object of the present invention to 
enhance the operation of a data network content server 
by enabling it to communicate transparently with an 
external billing and authentication server or service, e.g. 40 
an Internet Service Broker, to offer value-added logistic 
services. 

[0005] According to a first aspect of the present inven- 
tion there is provided a method of downloading 
resources to a client from a content server over a data 45 
network, the method comprising: 

sending a resource request message from the cli- 
ent; 

intercepting the sent resource request message at so 
a proxy located in the data network between the cli- 
ent and the content server; 
sending a header request from the proxy to the con- 
tent server requesting the content server to transmit 
a header, associated with the requested resource, 55 
to the proxy; 

receiving the header at the proxy and determining 
whether or not the header contains billing and/or 
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access restrictions; 

in the event that the header does contain billing 
and/or access restrictions, authenticating the cli- 
ent's right to receive the requested resource; and 
providing the client is authenticated, delivering the 
resource request message from the proxy to the 
content server and subsequently downloading the 
resource from the content server to the client. 

[0006] Preferably, said step of authenticating the cli- 
ent's right to receive the requested resource comprises 
conducting an authentication dialogue with an Internet 
Service Broker (ISB). The ISB is a software server plat- 
form which centralizes the logistic services on behalf of 
other content services. These logistic services include, 
without limitation, client identification and authentica- 
tion, access control to the network resources, unified 
billing interface and client identification delivery for serv- 
ice customization. The present invention may provide a 
method for implementing the interface for these logistic 
services for standard web server with standard HTML, 
such that there is no need to make any proprietary mod- 
ification. 

[0007] The authentication step may additionally com- 
prise a dialogue between the ISB and the client follow- 
ing the setting up of the dialogue between the proxy and 
the ISB. 

[0008] The present invention may be combined with 
the Internet Service Broker concept which is described 
in PCT/FI97/00426. 

[0009] Preferably, the proxy mediates and stores or 
caches data to minimize loading time of commonly 
requested resources. When a certain hypertext docu- 
ment is requested several times from one or more cli- 
ents, the subsequent request(s) may be met by giving 
the already fetched document instead of requesting it 
again from the original source. This generally requires 
confirmation that the original document has not 
changed between successive requests. 
[001 0] The proxy may be a program running on a sep- 
arate computer device placed In front" of the computer 
device on which the content server is running. Alterna- 
tively, the proxy is a program running on the same com- 
puter as the content server. The proxy monitors the data 
traffic and provides the required logistic service when a 
certain HTTP message is detected. 
[0011] According to a second aspect of the present 
invention there is provided a proxy for controlling billing 
and access in a data network, the proxy comprising; 

means for intercepting a resource request message 
sent from a client and intended for a content server; 
means for sending a header request to the content 
server requesting the content server to transmit a 
header, associated with the requested resource, to 
the proxy; 

means for receiving the transmitted header and for 
determining whether or not the header contains bill- 
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ing and/or access restrictions; 

means for authenticating the client's right to receive 
the requested resource in the event that the header 
does contain billing and/or access restrictions; and 
means for delivering the resource request message 
to the content server in the event that the client is 
authenticated. 

[001 2 J According to a third aspect of the present 
invention there is provided a computer memory 
encoded with executable instructions representing a 
computer program for causing a computer system con- 
nected to a data network to operate as a proxy, the 
proxy operating to: 

intercept a resource request message sent from a 

client and intended for a content server; 

send a header request to the content server 

requesting the content server to transmit a header, 

associated with the requested resource, to the 

proxy; 

receive the transmitted header and for determining 
whether or not the header contains billing and/or 
access restrictions; 

authenticate the client's right to receive the 
requested resource in the event that the header 
does contain billing and/or access restrictions; and 
deliver the resource request message to the con- 
tent server in the event that the client is authenti- 
cated. 

[0013] For a better understanding of the present 
invention and in order to show how the same may be 
carried into effect reference will now be made, by way of 
example, to the accompanying drawings, in which: 

Figure 1 is a schematic representation of the archi- 
tecture of an embodiment of the present invention; 
Figure 2 is a flow chart according to one embodi- 
ment of the present invention; and 
Figure 3 is a message semantic diagram according 
to one embodiment of the present invention. 

[0014] Figure 1 is a schematic presentation of the 
architecture of an embodiment of the present invention. 
A User or client 1 is the end user using a World Wide 
Web Browser which supports identification items which 
a WWW Server can give to the browser and which the 
browser stores and gives back only to the server it orig- 
inally received them from. These information items, e.g. 
cookies, enable the connection of several connection- 
less requests into a client session. 
[001 5] Proxy 2 is a software and/or hardware compo- 
nent that monitors the data traffic and takes care of the 
access control and billing using the Internet Service 
Broker (ISB) functionality. WWW Server 3 is a standard 
httpd program which delivers an HTML page, and pos- 
sible images, sound and other digital data linked into the 
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page, upon a client's request. The WWW Server 3 sup- 
ports client defined headers by, for example, .htaccess 
access control mechanism, custom headers or cgi-bin 
programs. Most current WWW servers, for example 
5 APACHE ™ or those provided by NETSCAPE ™ or 
MICROSOFT ™, have this functionality. 

[001 6] WWW Data Store 4 is a ffle system, database 
or the like, where the client accessible data is stored, 
whilst ISB 5 is the Internet Service Broker which defines 
io unified interfaces for client identification and authentica- 
tion, and for billing. Proxy Data Store 6 provides a cache 
in which the proxy 2 stores frequently requested docu- 
ments. 

[0017] Before describing the operation of a data 
is retrieving system used by the network of Figure 1 , it is 
useful to describe the nature and role of the so-called 
"Header" which is associated with request reply mes- 
sages sent over the Internet. The Header is a part of the 
message packet which contains control data related to 
20 the packet. For the purpose of the present example, 
these headers are part of the HTTP protocol (or HTTPS 
which is similar to HTTP but includes means for some 
security functionality). Thus, these headers have the fol- 
lowing form: 

25 

Header-field-name: value of the field 

in which the "Header-field-name" specifies the name of 
the header field and the "value of the field" is a charac- 

30 ter string, starting after the field separator ":" and ending 
with the next line feed. This header structure makes it 
relatively easy to add more functionality to the protocol 
by adding more fields, as long as the meaning of the 
existing fields is maintained. 

35 [001 B] An example of such a field is 

Content-length: 5345 

where field name defines that this field contains infor- 
40 mation about the amount of data in the message 
(excluding the header information) and the number in 
the value part of the field is interpreted as the data 
amount in bytes as implicitly defined by the meaning of 
field. The present method uses a packet that is built by 
45 following the same design principles as the protocol 
which it relies upon. However, whilst the usual use of the 
protocol headers is point-to-point connections (i.e. con- 
trolling the traffic from the starting point to the end point) 
or between two hops (i.e. two nodes directly connected . 
so together and interacting with each other), the use of the 
header fields in this method is to allow interception at a 
node (the "proxy") which is between the starting point 
and the end point. 

[001 9] The header is used to inform the intermediate 
55 node about billing information associated with a 
resource which can be purchased through a public con- 
nection network, e.g. the Internet, and which is intended 
to be intercepted by the intermediate node and to be 
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redirected to a third node (the "ISB") managing the 
actual billing. 

[0020] This method features a system in which the 
node from which the information originates, does not 
need to have a physical or even a logical connection to 
the node that manages the actual billing. Rather, the 
intermediate node interprets the billing information as 
presented by the originating node by using the conven- 
tions of the above mentioned protocol and using the 
header field or fields. The intermediate node then nego- 
tiates the billing process with the third node responsible 
for the actual billing processes. 
[0021 ] Figure 2 presents a transaction flow for the sit- 
uation where a web page is requested from the WWW 
Server 3. Client 1 requests 10 a page from the WWW 
Server 3 either by writing a specific Universal Resource 
Locator (URL) into its browser or by following a hyper- 
text link from some other hypertext document The 
browser dispatches a HTTP GET request The request 
is cached by the proxy 2 which handles all the requests 
directed to the WWW Server 3. The proxy requests the 
header information from the WWW Server 3 by dis- 
patching 12 a HEAD http request. In response to the 
HEAD request, the WWW Server 3 sends 13 the header 
information associated with the requested document to 
the proxy 2. 

[0022] From this header information the proxy 2 
parses out the billing and access information relating to 
the requested web page (the embedding of billing data 
is described in detail below). If the header information 
reveals that the requested resource has a price, but the 
proxy 2 has no valid cookie 14, the proxy 2 sends a bill- 
ing request 15 to the ISB 5. When receiving this 
request, the ISB 5 attempts to identify the client 1 by 
identifying his terminal means. This can be done if the 
connection to the service is initiated from a known 
source such as an in-house modem bank or tele-opera- 
tor, or an ISP managed Internet Access Point. 
[0023] If the billing requires any additional information 
from the client 1, ISB 5 asks the proxy 2 to present the 
client 1 with an identification and confirmation page 18. 
Prior to dispatching any dialogues, the proxy 2 sends a 
cookie 17 to the client's browser. In this way, it can later 
match the responses with correct requests. From now 
on the client 1 always sends the set cookie with every 
request directed to the proxy 2 or the WWW Server 3. 
[0024] After receiving and filling the requested identi- 
fication or confirmation information, the client 1 sends 
the data and the cookie 19 back to the proxy 2. Using 
this information, the proxy 2 dispatches another billing 
request 20 to the ISB 5. After the ISB 5 acknowledges a 
successful billing, the proxy 2 attempts to locate the 
requested resource (or page) in its cache. If the 
resource is present in the cache, and the earlier 
retrieved header indicates that the resource remains 
valid, the proxy 2 delivers 24 the cached resource to the 
client 1 . If the requested resource in not present in the 
cache, the original GET request is relayed 22 to the 



WWW Server 3. Then the WWW Server sends the 
requested resource to the proxy 2. where it is cached 
and forwarded 24 to the client 1. This ends the billing 
and access control transactions 25. 

5 [0025] Figure 3 is a message semantic diagram for the 
above described process, where the messages marked 
with "*" are not required if the billing can be done 
according to the identity of the User's terminal means. 
[0026] The following embodiment is used when the 

w present invention is implemented using the client 
defined HTTP header field with Apache WWW Server. 
The server is configured to add any new header infor- 
mation fields found at, for example, the .htaccess files. 
These files are used to attach access restrictions on 

is certain files or directories containing files or other direc- 
tories. The mechanism allows a default value to be 
specified for the whole directory or for specific proprie- 
tary values for specific files. 

[0027] The following is an example ".htaccess" file 
20 which adds a new field "Price" to the HTTP messages. 

< Directory /usr/local/httpd/commercial ) 

Header set Price 2.50 

(/Directory) 

25 ( Files Ajsr/locaiyhttpd/commercial/expensive.htm! > 
Header set Price 4.95 
(/Files) 

( Files /usr/local/httpd/commercial/cheapo.html ) 
Header set Price 1 .95 
30 (/Files) 

[0028] All files and directories located at the "commer- 
ciar directory are set to have a price of 2.50. In addition, 
the files "expensive.html" and "cheapo.html" are explic- 

35 itly set the prices of 4.95 and 1 .95 respectively. 

[0029] It will be appreciated by the person of skill in 
the art that various modifications may be made to the 
above described embodiment without departing from 
the scope of the present invention. For example, whilst 

40 the above embodiment has been described with refer- 
ence to retrieving data from a WWW server, the inven- 
tion may also be .applied to retrieving data from other 
types of data network servers and systems. 

45 Claims 

1 . A method of downloading resources to a client from 
a content server over a data network, the method 
being characterised by the steps of: 

50 

sending a resource request message from the 
client; 

intercepting the sent resource request mes- 
sage at a proxy located in the data network 
55 between the client and the content server; 

sending a header request from the proxy to the 
content server requesting the content server to 
transmit a header, associated with the 
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requested resource, to the proxy; 
receiving the header at the proxy and determin- 
ing whether or not the header contains billing 
and/or access restrictions; 
in the event that the header does contain billing s 
and/or access restrictions, authenticating the 
client's right to receive the requested resource; 
and 

providing the client is authenticated, delivering 
the resource request message from the proxy w 
to the content server and subsequently down- 
loading the resource from the content server to 
the client. 

2. A method according to claim 1 , wherein the step of is 
authenticating the client's right to receive the 
requested resource comprises conducting an 
authentication dialogue with an Internet Service 
Brofer (ISB). 

20 

3. A method according to claim 2, wherein the ISB is a 
software server platform which centralizes the 
logistic services on behalf of other content services. 

4. A method according to claim 2 or 3, wherein the 25 
authentication step additionally comprises a dia- 
logue between the ISB and the client following the 
setting up of the dialogue between the proxy and 

the ISB. 

30 

5. A method according to any one of the preceding 
claims, wherein the proxy caches previously 
requested resources to minimize loading time of 
commonly requested resources, the method com- 
prising determining whether or not a requested 35 
resource is present in the cache and, if present 
whether or not the cached resource is valid based 
upon data contained in the received header, 
wherein if the resource is present and valid the 
resource is sent from the proxy to the client whilst 40 
said resource request message is not delivered 
from the proxy to the content server. 

6. A method according to any one of the preceding 
claims, wherein the proxy is a program running on a 45 
separate computer device placed in front of the 
computer device on which the content server is run- 
ning. 

7. A method according to any one claims 1 to 5, so 
wherein the proxy is a program running on the 
same computer as the content server program. 

8. A method according to any one of the preceding 
claims, wherein the proxy conducts a confirmation 55 
dialogue with the client on the basis of instructions 
originating from an Internet Service Broker. 



9. A proxy for controlling billing and access in a data 
network, the proxy comprising; 

means for intercepting a resource request 
message sent from a client and intended for a 
content server; 

means for sending a header request to the con- 
tent server requesting the content server to 
transmit a header, associated with the 
requested resource, to the proxy; 
means for receiving the transmitted header and 
for determining whether or not the header con- 
tains billing and/or access restrictions; 
means for authenticating the client's right to 
receive the requested resource in the event 
that the header does contain billing and/or 
access restrictions; and 
means for delivering the resource request mes- 
sage to the content server in the event that the 
client is authenticated. 

10. A computer memory encoded with executable 
instructions representing a computer program for 
causing a computer system connected to a data 
network to operate as a proxy, the proxy operating 



to: 



intercept a resource request message sent 
from a client and intended for a content server; 
send a header request to the content server 
requesting the content server to transmit a 
header, associated with the requested 
resource, to the proxy; 

receive the transmitted header and for deter- 
mining whether or not the header contains bill- 
ing and/or access restrictions; 
authenticate the client's right to receive the 
requested resource in the event that the header 
does contain billing and/or access restrictions; 
and 

deliver the resource request message to the 
content server in the event that the client is 
authenticated. 
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